⚠️ Warning - these changes have not been tested on the corresponding hardware / setup / boards!

PR Description

This PR addresses timing violations observed across multiple projects following the upgrade to Vivado 2025.1, without requiring any HDL modifications.

After the upgrade, most designs exhibited hold violations, likely due to Vivado's aggressive optimization for setup timing. This behavior appears to shorten certain paths excessively, inadvertently introducing hold issues. While invoking phys_opt_design post-route helped resolve some violations automatically, it was not consistently effective, particularly in congested regions where rerouting options were limited.

To mitigate this, the Congestion_SpreadLogic_high strategy was adopted (alternatively _medium or _low depending on design needs). This approach encourages a more distributed placement of logic, which not only alleviates congestion but can also accelerate implementation due to the relatively low resource utilization. Although this spreading may introduce setup timing challenges, a subsequent phys_opt_design pass (or two) has proven highly effective at resolving them.

By spreading the logic and reducing congestion, Vivado gains greater flexibility during post-route optimization, improving its ability to correct HOLD violations without manual intervention.

Change log

• implemented scripts/auto_timing_fix.tcl
• improvements to projects/scripts/adi_project_xilinx.tcl
  • added ADI_MAX_THREADS so the trade-off between speed and RAM usage can be adjusted
  • added post place and route script flag
  • added documentation for other flags
• fixed timing issues in fmcomms2 with 2025.1 toolchain without hdl changes
  • project presented hold timing violations on vivado 2025.1
  • "phys_opt_design -hold_fix" resolved it for most variations but not for all of them
  • changed implementation strategy to spread placement on board to make hold timing easier to resolve
  • now all projects finish successfully after the auto fix script runs
  • no HDL changes were made
• fixed timing for ad9081 on vcu118 for specific make parameters
  • presented setup timing violations
  • use of "spread high" strategy solved issues without need of ATF or HDL changes

PR Type

• Bug fix (change that fixes an issue)
• New feature (change that adds new functionality)
• Breaking change (has dependencies in other repos or will cause CI to fail)
• Documentation

PR Checklist

• I have followed the code style guidelines
• I have performed a self-review of changes
• I have compiled all hdl projects and libraries affected by this PR
• I have tested in hardware affected projects, at least on relevant boards
• I have commented my code, at least hard-to-understand parts
• I have signed off all commits from this PR
• I have updated the documentation (wiki pages, ReadMe files, Copyright etc)
• I have not introduced new Warnings/Critical Warnings on compilation
• I have added new hdl testbenches or updated existing ones